The BDD Books - Discovery

https://gyazo.com/ee6982ea08cdafea9fd9b61ec0e470e6

なぜこの本を読んだか

このタイミングで積読から手に取ったのは、本業でテスト観点のレビューやテストについて考える機会があったためというのと夏休みが残り少なくなってしまいしゅっと読めるものを探してたから。

何が書かれている本か

BDD の本というタイトルがついてはいるものの、想像するような Given/When/Then のシナリオ形式で自動テストを書くという話ではなく (そもそも本書の中でも以下のようにかなり下流の工程であることが触れられている) いわゆるテストのシフトレフトに代表されるようなプロジェクト全体にテスターが関わっていくという話が書かれていた。

多くの開発チームは、テスト自動化を改善したいという願望から BDD にやって来ます。テスト自動化の改善は、BDD のアプローチに従うことの重要なせいかの1つですが、それは下流の成果です。説明している順序 (発見、定式化、自動化の順) でプラクティスを採用しない限り、期待されるメリットは得られません。

英語版では、「定式化」の続編が出ていた

メモ

BDDとは何か

これがこの本の全てのような一節

BDD はアジャイルなアプローチであり、順番に取り組む必要のある 3 つのプラクティ スで構成されています。 最初のプラクティスは発見 (Discovery) です。 これは、明確な 具体例の使用による構造化された協調作業です。 これにより、従来のソフトウェアプロ ジェクトで躓いてきたあいまいさや誤解を明らかにできます。

2 番目のプラクティスは、定式化 (Formulation) です。 これは、発見のプラクティスで 作成した明確な具体例をビジネスチームのメンバーが読みやすいシナリオに変える創造的 なプロセスです。 その後に行うシナリオのレビューにより、ビジネスが求めているもの をチームが本当に理解しているという確信を得ます。

3 番目であり最後のプラクティスは自動化 (Automation) で、シナリオをテストに変えるコードを記述します。 自動化のメリットは下記のように多岐にわたります。

こういった発見を開発中に見つかって計画の変更を強いられるような「偶発的な発見」と比較して「計画的な発見」 (おそらく意図的な発見とかそういう感じかなと行間を読んだ) と呼んでいる。

また、具体例 (Example) は以下の図のようにコンテキスト、アクション、結果の3つに分解できるという部分も普段からなんとなくこういう整理をしていた自分としては言語を獲得したように思うのでよかった。

https://gyazo.com/95128a39ecb9f97b306d096b46142157

ここでいうコンテキストは、アクションが実行される前のシステムの状態のことを指す。

(自分はこの整理をする度に State Monad っぽい感覚にいつもなる)

最後の方にさまざまなツール上で実例マッピングを付箋以外でどうやって絵として表現するかというのが紹介されていてよかった。特に自分は普段から PlantUML を利用したりするので以下のようなマインドマップ形式がよかったなと感じた。

https://gyazo.com/06f326dc9d86ee4bf0bb388e35ff7b12

感想

実例マッピングのコンセプトを紹介する本やブログ記事などのリソースは増えてきたもののそれこそ具体的なシチュエーションをベースにしてどうやっていくかが会話形式で割と詳細に書かれているのはよかった。

また、上にもあるように「コンテキスト」＋「アクション」-> 「結果」という構図を普段からなんとなく意識していたが今後はこの本で書かれていたというように引用していこうかなと思う。